The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
The term “Web services” describes a standardized way of integrating Web-based applications using the XML, SOAP, and WSDL standards over a networking protocol, such as IP. XML is used to tag the data, SOAP specifies how to encode a Web service request and response into an XML message, and WSDL is used for describing the services available. Web services are used for programmatic and networked entities to communicate with each other, regardless of the platform for their implementation. Because many such entities are business-related, Web services allow businesses to communicate data without intimate knowledge of each other's IT systems behind a firewall.
Web services share business logic, data, and processes through a programmatic interface across a network. Web services allow different applications from different sources to communicate with each other without time-consuming custom coding. And, because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Python and Windows applications can talk with UNIX applications.
Web Services specifications compose together to provide interoperable protocols for security, reliable messaging, and transactions in loosely coupled systems. Web Services specifications include both approved standards (e.g. by the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS)) and proposed documents and drafts that may become standards.
Typically, Web service applications (WSAs) are tied to (or implement) one or more Web Services (WS) specifications. Therefore, WSAs do not recognize the information that is not defined in the specification, even though the corresponding fields are valid per schema.
WSAs need to be updated when the corresponding WS specifications are modified because some client applications may want to take advantage of the modifications. However, a device providing a WSA should remain compliant with older versions of the WS specifications in case client applications that request the service provided by the WSA have not yet been updated to reflect the modifications.
One approach for responding to a WS specification modification is to develop another WSA, which entails undergoing (again) the various phases of the software development process—design, coding, testing, documentation, and maintenance—which is typically quite costly. As a result of this approach and after a series of modifications to a WS specification, there may be multiple WSAs that (a) provide the same basic service and (b) execute simultaneously. Having multiple similar WSAs executing simultaneously requires additional memory and processing power.
In a similar approach, a new WSA is developed that takes into account an old version and the new version of the WS specification. However, as a result of this approach, the old WSA must be taken down before the new WSA is brought up. Thus, the services provided by the WSA may be temporarily unavailable.